error codes: provide error codes on stream reset and connection close #623
Conversation
| [RFC](https://www.rfc-editor.org/rfc/rfc9000.html#section-19.19-6.2.1). | ||
|
|
||
| ### Yamux | ||
| Yamux has no `STOP_SENDING` frame, so there's no way to signal an error on |
There was a problem hiding this comment.
I wonder if there's an addition we could add to the spec to support this in a backwards compatible way. Not worth doing now, but maybe could be added in the future.
There was a problem hiding this comment.
I made some suggestions for the wire encoding in #479. You'd have to check if existing implementations handle this gracefully.
There was a problem hiding this comment.
@marten-seemann do you mean suggestions for sending an error code? There's this PR for yamux for that #622
There was a problem hiding this comment.
@MarcoPolo I think we can add this, there are 16 flag bits, so we do have space for a new flag and implementations only look at the flag bits they care about. I created #627
error-codes/README.md
Outdated
|
|
||
| Error codes provide a best effort guarantee that the error will be propogated to | ||
| the applciation layer. This provides backwards compatibility with older nodes, | ||
| allows smaller implementations and using transports that don't provide a |
There was a problem hiding this comment.
Do we mean "less popular" here maybe?
| allows smaller implementations and using transports that don't provide a | |
| allows less popular implementations that are using transports that don't provide a |
There was a problem hiding this comment.
I'm not sure about popularity here - maybe "simpler" instead of "smaller"?
Either way this needs an Oxford comma:
| allows smaller implementations and using transports that don't provide a | |
| allows smaller implementations, and using transports that don't provide a |
There was a problem hiding this comment.
I actually do prefer "smaller" in terms of code size smaller. I like simpler too. Happy to change if you have strong opinions.
| information to the receiver. Receiving a `Bad Request: Connection Closed` error | ||
| on reading from a stream also tells the receiver that no more streams can be | ||
| started on the same connection. Implementations MUST provide the Connection | ||
| Close error code on streams that are reset as a result of remote closing the |
There was a problem hiding this comment.
| Close error code on streams that are reset as a result of remote closing the | |
| Close error code on streams that are reset as a result of the remote closing the |
error-codes/README.md
Outdated
| In the event that a node detects violation of a protocol or is unable to | ||
| complete the necessary steps required for the protocol, it's useful to provide a | ||
| reason for disconnection to the other end. This error code can be sent on both |
There was a problem hiding this comment.
It's broader than this. This doesn't only apply to protocol violations (which should be rare), but also to common events like running into resource limits, connections being pruned by the connection manager, etc.
There was a problem hiding this comment.
I've rephrased this and removed the specific reference to protocol errors.
| [RFC](https://www.rfc-editor.org/rfc/rfc9000.html#section-19.19-6.2.1). | ||
|
|
||
| ### Yamux | ||
| Yamux has no `STOP_SENDING` frame, so there's no way to signal an error on |
There was a problem hiding this comment.
I made some suggestions for the wire encoding in #479. You'd have to check if existing implementations handle this gracefully.
error-codes/README.md
Outdated
| For Connection Close, the 32bit Length field is to be interpreted as the error | ||
| code. The error code MUST be sent as an Big Endian unsigned 32 bit integer. | ||
|
|
||
| For Stream Resets, the error code is sent as the first 4 bytes of the Data Frame |
There was a problem hiding this comment.
Linking this here since this will change: #622 (comment)
sukunrt
force-pushed
the
error-codes
branch
from
3b23cde
to
070f090
Compare
Do we need to? Application protocols can have conflicting error codes. From the application context, it's clear which is the relevant error. I am planning to reserve a space for libp2p to use for its errors and let applications do whatever they like with the application error codes space. |
They're not conflicting, since the application protocol is negotiated during the QUIC handshake.
This is not correct, thanks to multistream. |
sukunrt
force-pushed
the
error-codes
branch
from
d0db0b2
to
3060cd0
Compare
|
I see. All connections are just libp2p connections and they can speak multiple application protocols any of which may close the underlying connection on error. |
No description provided.